fix: cap the length of a string handed to the parsers CVE-2026-60075 - #55

_parse_time removes a time from anywhere in the string with the
unanchored substitution s/$timerx/ /, where $timerx is an auto-generated
alternation of time patterns reached through a leading (?:$atrx|^|\s+).
The engine retries the match at every position of an interior whitespace
run: at each start position the leading \s+ consumes the rest of the run
greedily, the time alternation fails because the run holds no digits,
and the engine backtracks a space at a time across the run before
advancing the start position.  The cost is quadratic in the length of
the run, and no time need be present in the string.  On the machine this
patch was tested on, parsing "x" . (" " x 2000) . "x" took 1.7 seconds
of CPU and "x" . (" " x 16000) . "x" took 107 seconds, rising about
fourfold for each doubling of the run.

This fix rejects a string longer than a configurable $MAXLENGTH (256) at
the parse and parse_time entries, before any regex runs.  Legitimate
date strings are well under 100 characters, and a 42 entry corpus of
legitimate formats parses to the same value before and after.